API docs: clarify ICMP related.#364
Conversation
✅ Deploy Preview for kubernetes-sigs-network-policy-api ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
danwinship
left a comment
There was a problem hiding this comment.
Should mention that the Networks peer selects both IP/IPv4 and ICMP/ICMPv6 traffic too.
| // the destination. No further ClusterNetworkPolicy or | ||
| // NetworkPolicy rules will be processed. | ||
| // - Accept: Accepts the selected traffic, and ensures that response | ||
| // traffic including "related" ICMP traffic is also allowed. No further |
There was a problem hiding this comment.
I'd at least put a comma before "including", but maybe "Accepts the selected traffic, including replies to that traffic and related ICMP traffic." (and likewise in the other places with the same text).
| Each CNP should define at least one `Ingress` or `Egress` relevant in-cluster traffic flow | ||
| along with the associated Action that should occur. In each `gress` rule the user | ||
| Each CNP should define at least one `Ingress` or `Egress` relevant in-cluster traffic flow | ||
| along with the associated Action that should occur. In each `gress` rule the user |
There was a problem hiding this comment.
I think there's an issue about getting rid of the non-word "gress" everywhere, so let's start here. You can just drop it entirely and say "each rule".
| along with the associated Action that should occur. In each `gress` rule the user | ||
| Each CNP should define at least one `Ingress` or `Egress` relevant in-cluster traffic flow | ||
| along with the associated Action that should occur. In each `gress` rule the user | ||
| should AT THE MINIMUM define an `Action`, and at least one `ClusterNetworkPolicyPeer`. |
There was a problem hiding this comment.
| should AT THE MINIMUM define an `Action`, and at least one `ClusterNetworkPolicyPeer`. | |
| should *at the minimum* define an `Action`, and at least one peer (`To` or `From` entry). |
| along with the associated Action that should occur. In each `gress` rule the user | ||
| should AT THE MINIMUM define an `Action`, and at least one `ClusterNetworkPolicyPeer`. | ||
| Optionally the user may also define select `Ports` to filter traffic on and also | ||
| Optionally the user may also define select `Protocols` to filter traffic on and also |
There was a problem hiding this comment.
| Optionally the user may also define select `Protocols` to filter traffic on and also | |
| Optionally the user may also select `Protocols` to filter traffic on and also |
| should AT THE MINIMUM define an `Action`, and at least one `ClusterNetworkPolicyPeer`. | ||
| Optionally the user may also define select `Ports` to filter traffic on and also | ||
| Optionally the user may also define select `Protocols` to filter traffic on and also | ||
| a name for each rule to make management and reporting easier for Admins. |
There was a problem hiding this comment.
| a name for each rule to make management and reporting easier for Admins. | |
| a `Name` for each rule to make management and reporting easier for Admins. |
|
|
4538b54 to
d158588
Compare
tssurya
left a comment
There was a problem hiding this comment.
can't tell why the CI is red https://prow.k8s.io/view/gs/kubernetes-ci-logs/pr-logs/pull/kubernetes-sigs_network-policy-api/364/pull-network-policy-api-verify/2039649007680098304
very weird "Test started last Thursday at 12:19 PM failed after 49h42m18s."
| // - Accept: Accepts the selected traffic, allowing it into | ||
| // the destination. No further ClusterNetworkPolicy or | ||
| // NetworkPolicy rules will be processed. | ||
| // - Accept: Accepts the selected traffic, including replies to that |
There was a problem hiding this comment.
We spoke a bit about this during AMS KubeCon,
but a note for future that since we have made this explicit we do need to consider this while designing the ICMP protocol match whether ICMP protocol match will also allow related or if its purely restricted to specific independent types and codes.
just highlighting it for history (no action required from this comment)
There was a problem hiding this comment.
There's some trickiness here, but I would hope that conntrack deals with it all for us.
If you allow ICMP pings, you would also have implicitly be allowing the replies to that ping, just like in the IP case.
| // ClusterNetworkPolicyRuleActionAccept indicates that | ||
| // matching traffic will be accepted and no further policy | ||
| // evaluation will be done. This is a final decision. | ||
| // ClusterNetworkPolicyRuleActionAccept stops further rule processing of |
There was a problem hiding this comment.
hmm interesting..I am trying to find the nuance/motivation behind the change here and for the other actions..
so ACCEPT in ingress rules being hit doesn't mean the policy stops being evaluated but we still evaluate the egress rules?
OR
is there something between policy v/s rules?
There was a problem hiding this comment.
Traffic from pod A to pod B goes through pod A's egress rules and pod B's ingress rules. The change was intended to hint that pod A's "egress accept" may still get blocked by pod B's ingress rules.
TBH I started just trying to make the language more direct. "stops and accepts" instead of "indicates that ..."
| // - Deny: Drops the selected traffic. No further | ||
| // ClusterNetworkPolicy or NetworkPolicy rules will be | ||
| // processed. | ||
| // - Deny: Drops the selected traffic. No further ClusterNetworkPolicy or |
There was a problem hiding this comment.
I recently learnt that networkpolicies when created mid way do expect to effect existing connections? so for both DENY and PASS it actually does include ICMP related as well for that connection?
There was a problem hiding this comment.
For networkingv1.NetworkPolicy there is no official expectation about what happens when you create a NetworkPolicy that matches a pre-existing connection. For CNP we're leaning toward "it breaks existing connections" but we never finished that discussion (#305).
| Each CNP should define at least one `Ingress` or `Egress` relevant in-cluster traffic flow | ||
| along with the associated Action that should occur. In each rule the user | ||
| should *at the minimum* define an `Action`, and at least one peer (`To` or `From` entry). | ||
| Optionally the user may also select `Protocols` to filter traffic on and also |
There was a problem hiding this comment.
I would remove this from this PR since https://github.com/kubernetes-sigs/network-policy-api/pull/363/changes#diff-a6c5effcce61a6f6fa4724456fa5ef6c7cf5d72306dce662570e1429c6776e3dR124 there is an earlier PR here that is doing that change so I can review that separately..the changes to the first part To and From makes sense
I don't want to leave the other contributor hanging (sweat smiley)
| // | ||
| // Networks matches both regular IP traffic and ICMP traffic to/from | ||
| // the specified CIDRs. For example, a Networks entry of "0.0.0.0/0" | ||
| // will match both IPv4 and ICMP traffic, while "0::/0" will match |
082cea5 to
2a1070f
Compare
|
lgtm, but needs a rebase |
|
and can you squash the fixup commits? |
2a1070f to
ee67a7d
Compare
|
Done |
Note that ICMP related packets (such as TOOBIG) are allowed when allowing the main protocol connection. Improve wording in various places.
ee67a7d to
cadb73e
Compare
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: fasaxc, tssurya The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Clarify that ICMP related packets (such as TOOBIG) are included when accepting traffic. Tighten up action descriptions and improve formatting in various places.
PR generated with assistance of AI (Claude).